Day 10：Vibe Coding 的致命傷：不懂基礎語法會踩到的雷與 Debug 心法

嗨，大家今天過得好嗎？歡迎來到鐵人賽 Day 10。

過去這幾天，我們靠著 Vibe Coding 和結構化的 Prompt，用極快的速度在 Xcode 裡搭出了符合 MVC 架構、帶有動畫與 Mock Data 的精美前端介面。這過程是不是覺得很爽、很有成就感？

但今天，我想暫停一下，來聊點比較刺耳的「現實面」。

在 AI 開發的浪潮下，很多人提倡「未來工程師不需要懂程式碼，只要會下 Prompt 就好」。這句話我只同意一半。如果你只是想做個單頁的玩具，那確實沒問題；但如果你要做的是一個具備商業邏輯、未來需要維護的全端應用，「不懂基礎語法」絕對是 Vibe Coding 的致命傷。

踩雷實錄：當 AI 開始「通靈」

在使用 AI 寫 Swift / SwiftUI 時，如果你完全沒有語法基礎，最常會被以下兩種狀況搞死：

1. 幽靈變數與幻覺 API (Hallucination)

LLM 最大的缺點就是「太想討好你」。有時候它為了達成你的排版要求，會自己發明一些根本不存在的 Modifier，或是套用最新版 iOS 才有的 API，但你的專案明明是設定在舊版 iOS。

另一個常見的雷是「變數名稱對不起來」。例如我們的 Model 裡明明叫 requestData，但 AI 在寫 View 的時候，可能因為上下文遺失，自己通靈改成了 $controller.formData。
如果你不懂基礎語法，看到 Xcode 噴出紅字，你只會覺得「天啊！程式壞了！」，完全不知道其實只要改一個單字就能解決。

2. 無限複製貼上的「報錯地獄」

這是我看過新手最常陷入的死胡同。
當 Xcode 噴錯時，新手的標準動作是：把錯誤訊息複製 ➔ 貼給 AI ➔ 拿到新 Code ➔ 整個檔案覆蓋貼上。

結果呢？AI 為了解決 A 錯誤，不小心把 B 功能的邏輯刪掉了，或是破壞了我們辛辛苦苦建立的 MVC 架構。於是又跑出新的錯誤，你再貼給 AI... 重複三次之後，你的專案就徹底爛成一坨無法挽救的毛線球了。

Vibe Coding 時代的 Debug 破局心法

要避免上述的慘劇，你必須建立一套在 AI 協作時代專屬的 Debug 思維：

心法一：先看懂錯誤訊息，不要急著餵狗 (AI)

Xcode 的報錯其實有時候滿精準的。如果它說 Value of type 'HomeController' has no member 'submit'，這就白話文告訴你：你的 Controller 裡面沒有 submit 這個函數（我們明明命名為 submitRequest）。
看到這種錯，請直接手動把名字改對就好，不要把整個檔案丟給 AI 叫它重寫。你每讓 AI 重寫一次大檔案，架構走鐘的風險就增加一分。

心法二：隔離問題，精準打擊

如果真的遇到不懂的邏輯錯誤，需要請 AI 幫忙時，請務必「縮小範圍」。
不要丟整個 ContentView.swift，而是只丟出問題的那段函數：

❌ 「這整份檔案報錯了，幫我修好。」
✅ 「在我的 submitRequest() 函數中，我想要做非同步的 API 呼叫，但編譯器報錯 async call in a function that does not support concurrency，請問我該如何修改這個函數？」

心法三：鎖定版本與框架範圍

在你的 Prompt 裡，除了昨天教的【角色＋架構＋任務＋限制】之外，如果遇到踩坑，請加上「環境宣告」。
例如：「請注意，我的專案是基於 iOS 16 與 SwiftUI，請不要使用 iOS 17 以上的 API，也請不要使用 UIKit 的包裝。」這能大幅減少 AI 產出無法編譯的廢 Code。

前端階段小結

這 10 天下來，我們已經把前端的底子打好了。我們有一個漂亮的殼，而且有一個預留好的 APIService 隨時準備跟後端對接。我們證明了：只要你有架構思維（MVC）加上好的 Prompt 框架，Vibe Coding 就能成為你最強的武器。

但我們的 App 現在還只是個會自言自語的空殼。

明天開始，這場鐵人賽將進入第二個高潮！我們要把戰場轉移到 Day 3 架設好的 n8n 視覺化工作流。我們要開始「畫」出後端邏輯，並建立我們的第一支 Webhook API！

準備好把前後端打通了嗎？我們 Day 11 見！